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(54) Ressourcen-Management-Verfahren fur ein verteiltes System von Teilnehmern 



(57) Bei einem Ressourcen-Management-Verfah- 
ren fiir ein verteiltes System von Teilnehmern (i.f. "Res- 
sourcen" genannt), die durch mehrere Controller ge- 
steuert werden und die miteinander kommunizieren, be- 
sitzen die Controller verschiedene und teilweise unter- 
einander gleiche Prioritat. Jede Ressource wird von ei- 



nem Controller solange gesteuert solange dieser und 
solange kein Controller mit hoherer Prioritat auf sie zu- 
greift. Von den Controllern, die die Ressource benoti- 
gen, steuert der mit der hochsten Prioritat die Ressour- 
ce und von mehreren Controller mit der gleichen hoch- 
sten Prioritat steuert derjenige die Ressource, der als 
erster auf sie zugreift. 
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Beschreibung 

[0001] Die Erfindung bezieht sich auf ein Ressourcen-Management-Verfahren fur ein verteiltes System von Teilneh- 
mern (Lf. "Ressourcen" genannt), die als Hardwarekomponenten Oder aber auch als Softwaremodule ausgebildet sind, 
5 die durch mehrere Controller gesteuert werden und die uber ein Bussystem oder uber eine gerateinterne Software- 
schnittstelle miteinander kommunizieren. 

[0002] Applikationen sind Einheiten in Hard- und Software, die dem Kunden oder dem System eine Funktionalitat 
zur Verfugung stellen. Dabei gibt es grundlegende Applikationen, sog. Ressourcen, die funktionale Bausteine fur ein 
System darstellen (ein CD-Laufwerk, ein Tuner, ein Telefon, ein Mikrofon, ein Amplifier etc.). Diese Ressourcen werden 

10 von hierarchisch hohergestellten Applikationen, sog. Controllern, z.B. einem zentralen Mensch-Maschine-lnterface 
(MMI) verwendet (gesteuert), urn dem Nutzer eine insgesamt hdherwertige Funktionalitat zur Verfugung zu stellen (z. 
B. Funktionalitat Telefon Freisprechen durch Verwendung der Ressourcen Mikrofon, Telefon und Amplifier mit Laut- 
sprechern). Die Controller verkniipf en die Ressourcen zu einem System im Dienste des oder der Nutzer. 
[0003] In einem groBeren System, wie dem Infotainmentsystem in einem Fahrzeug gibt es oftmals mehrere Con- 
's troller, die auf die gleichen Ressourcen zugreifen. Ein Beispiel sind mehrere MMIs fur Front- und Fondpassagiere. Von 
jeder MMI aus kann der Nutzer den CD-Wechsler bedienen. Grundsatzlich ist zu unterscheiden zwischen exklusiven 
Ressourcen, die jeweiis nur von einem Controller benutzt werden konnen, wie z.B. einem Telefon, und shared Res- 
sources, die andere Controller mitbenutzen konnen, wie z.B. die Audio-CD im CD-Wechsler, die durch mehrere Nutzer 
angehdrt werden kann (z.B. uber Lautsprecher und uber Kopfhorer). 

20 Bei der Benutzung von Ressourcen durch mehrere Controller kann es zu Zugriffskonflikten kommen, z.B. wenn von 
mehreren MMIs gleichzeitig auf die gleiche Ressource zugegriffen wird (z.B. der eine Nutzer will Track 5 der CD horen 
und der andere Track 9). Aber auch fur den menschlichen Nutzer nicht direkt sichtbare Controller konnen auf die 
Ressource zugreifen wollen. So konnte beispielsweise ein Navigationssystem auf eine Karten-CD-ROM zugreifen 
wol!en : die sich im selben CD-Wechsler befindet wie die gerade gehorte Audio-CD. Es gibt Multimedia-Wechsler, die 

25 Audio-, Video- oder ROM-Disks abspielen konnen. 

[0004] Heutige Infotainmentsysteme in Fahrzeugen sind meist historisch gewachsen. Ein gezieltes Ressourcenma- 
nagement findet nicht statt. Jeder Controller versucht, durch Beobachtung des Systemzustandes herauszufinden, ob 
er gerade auf eine Ressource zugreifen kann. Da die Systeme immer komplexer werden, wird auch diese Aufgabe 
immer schwieriger. Der Entwicklungsaufwand, urn alle Eventualitaten abzudecken, ist sehr hoch - die Qualitat des 

30 Ergebnisses ist entsprechend niedrig. 

[0005] In zentralen Systemen, die sich in einer Hardwareeinheit befinden, wie z.B. in einem PC ist die Verwaltung 
von Ressourcen durch Mechanismen im Betriebssystem gut geregelt. Oftmals ist eine spezielle Applikation realisiert, 
der sog. Ressourcenmanager, bei dem Controller den Zugriff auf eine Applikation beantragen und der je nach Prioritat 
der Controller die Ressource einem Controller zuteilt. Eine weitere in zentralen Systemen verwendete Methode sind 

35 sog. Semaphoren (Ampeln), die anzeigen, ob eine Ressource gerade benutzt wird oder nicht. Sie stellt einen dezen- 
tralen Mechanismus dar, da jeder Controller selbst beurteilt, ob er auf die Ressource zugreifen kann oder nicht. 
[0006] Meist werden diese Methoden auch fur verteilte Systeme verwendet. Ein Betriebssystem kann hier jedoch 
nicht verwendet werden. In einem verteilten System werden mehrere verschiedene Betriebssysteme eingesetzt, daher 
miissen allgemeine Mechanismen definiert werden und kann nicht auf die Mechanismen eines einzelnen Betriebssy- 

40 stems zuruckgegriffen werden (die Mechanismen werden uber mehrere Hardware-Einheiten hinweg verwendet und 
nicht nur in einer Einheit). Daher bleiben Ressourcenmanager und Semaphoren. 

[0007] Fur ein zumindest zum Teil verteiltes System wie dem Infotainmentsystem des Fahrzeugs, bei dem sich Res- 
sourcen und die verschiedenen Controller in mehreren Hardwareeinheiten befinden konnen und zumindest zum Teil 
uber ein Bussystem, ansonsten uber eine Software- Schnittstelle kommunizieren, ist ein zentraier Ressourcenmanager 

45 nicht optimal. Er mu(3 den Zustand des verteilten Systems sehr genau beobachten, urn beurteilen zu konnen, welcher 
Controller in welcher Situation gerade Prioritat hat. Dazu ist sehr viel Kommunikation zwischen dem System und dem 
Ressourcenmanager notwendig. Zudem mu(3 er sehr genau auf das spezielle System ausgelegt werden. Ergeben sich 
durch Ausstattungsvarianten, Weiterentwicklungen oder andere Fahrzeugmodelle Anderungen im System und in der 
Prioritatsverteilung, muG der Ressourcenmanager jeweiis darauf a ngepaBt werden. Zudem bildet der Ressourcenma- 

50 nager neben den Controllern, eine weitere Einheit, die das System steuert. Alle solchen Einheiten mussen mit ent- 
sprechendem Aufwand aufeinander abgestimmt werden. Aus diesen Griinden ist der zentrale Mechanismus einer 
Ressourcenmanagers in verteilten Systemen ungunstig. 

[0008] Der dezentrale Mechanismus unter Verwendung von Semaphoren ist jedoch auch nicht ausreichend. Eine 
Semaphore (Ampel) besagt lediglich, ob eine Ressource belegt ist oder nicht. Sie sagt nichts daruber aus, wer die 
55 Ressource gerade belegt und gestattet kein Ressource Sharing. 

[0009] Der Erfindung liegt die Aufgabe zugrunde, ein dezentrales Verfahren der eingangs genannten Art zu schaffen, 
das mit geringem Aufwand in verteilten Systemen einen Zugriff auf die vorhandenen Ressourcen regelt und damit 
Zugriffs-Konfliktauflosung und Ressourcen Sharing ermoglicht. 
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[0010] Die Erfindung lost diese Aufgabe dadurch, daB die Controller verschiedene und teilweise untereinander glei- 
che Prioritat besitzen. daB jede Ressource von einem Controller solange gesteuert wird : solange dieser und solange 
kein Controller mit hoherer Prioritat auf sie zugreift, daB von den Controllern, die die Ressource benotigen, der mit der 
hochsten Prioritat die Ressource steuert, und daB von mehreren Controllern mit der gleichen hochsten Prioritat der- 

5 jenige die Ressource steuert, der als erster auf sie zugreift. 

[0011] Vorteilhafte Ausgestaltungen der Erfindung sind in den Patentanspruchen 2 bis 5 beschrieben. 
[0012] Die Erfindung besteht in einer Eigenschaft, die jede Ressource zur Verfugung stellt. Eine Eigenschaft ist ein 
Begriff aus der objektorientierten Programmierung (engl. Property) und stellt im wesentlichen einen Speicherplatz dar, 
der einen bestimmten Wert (oder eine Eigenschaft) annehmen kann. Hier ist auf dem Speicherplatz eine Liste gespei- 

10 chert in die sich mehrere Controller mit ihrer jeweiligen Prioritat eintragen konnen. Die Ressource kennzeichnet in der 
Liste den Controller, dem die Ressource "gehorf. Er ist der "Owner" der Ressource. Vorteilhafterweise erfolgt die 
Kennzeichnung durch die Ressource dadurch, daB die Liste nach Prioritaten geordnet wird. Der Controller mit der 
hochsten Prioritat steht am Anfang der Liste. Er ist der Owner der Ressource. Alle anderen eingetragenen Controller 
konnen die Ressource mitbenutzen. Dabei muB ein Controller aus der Art der Ressource schlieBen, wie weit er mit 

15 der Mitbenutzung gehen kann. Eintrage von Controllern gleicher Prioritat werden nach dem Zeitpunkt der Eintragung 
absteigend geordnet. 

[0013] Im foigenden Beispiel ist die Liste einer Ressource 1 zu drei aufeinanderfolgenden Zeiten dargesteltt. Zu- 
nachst ist nur der Controller 4 eingetragen und damit der Owner der Ressource. Zum Zeitpunkt 2 hat ihn Controller 3 
mit hoherer Prioritat zum Mitbenutzer gemacht. Controller 3 ist nun der Owner. Er kann von diesem Platz durch den 
20 zum Zeitpunkt 3 dazugekommenen Controller 7 mit gleicher Prioritat nicht vertrieben werden. 

Zeitl Zeit2 Zeit 3 

25 Ressource 1 Liste Ressource 1 Liste Ressource 1 Liste 

Owner Controller 4, Prio 2 Controller 3, Prio 1 Controller 3, Prio 1 
Mitbenutzer Controller 4, Prio 2 Controller 7, Prio 1 

30 Mitbenutzer Controller 4, Prio 2 

[0014] Bendtigt ein eingetragener Controller die Ressource nicht mehr, tragt er sich aus. Ist noch ein Mitbenutzer 
eingetragen, erkennt der sich verabschiedende Owner daB er die Ressource nicht verandern darf (z.B. Anhalten des 
35 CD-Players). Auf die Eigenschaft bzw. die Liste kann von extern, d.h. uber den Bus oder die Software-Schnittstelle 
zugegriffen werden, d.h. eine Funktionseinheit Controller kann den Speicher in der gesteuerten Funktionseinheit be- 
schreiben und sich dort ein- bzw. austragen. Vorteilhafterweise schreibt der Controller nicht direkt auf bestimmte Spei- 
cherzellen der Ressource, sondern indirekt indem er in der gesteuerten Funktionseinheit eine Routine aufruft, die das 
dann tut. 

40 [0015] Die Verwaltung der Liste und Kennzeichnung des Owners, z.B. durch Sortierung der Liste wird von der Res- 
source selbst ubernommen. Die Ressource laBt die Speicherstelle von den auf sie zugreifenden Controllern fullen oder 
leeren (Eintrag bzw. Austrag), sie sortiert die Liste lediglich. Sonst hat die Liste jedoch keinen EinfluB auf die Funktio- 
nalitat der Ressource, d.h. die Ressource wird nicht fiir die Steuerung durch den Owner reserviert. Bei jeder Veran- 
derung in der Liste wird alien Controllern der neue Zustand der Liste mitgeteilt. 

45 [0016] Durch die Erfindung ergibtsich ein einfacherabersehr leistungsfahigerundflexiblerMechanismuszum Res- 
sou rcenmanagement. Sie stellt einen dezentralen Mechanismus dar, der eine komplexe zentrale Verwaltungseinheit, 
wie einen Ressourcenmanager eriibrigt. 

[0017] Im Gegensatz zu einem Semaphorenmechanismus, bei dem ein Controller nur sieht, ob eine Ressource 
gerade gesperrt ist, ist bei einem erfindungsgemaBen Verfahren jeder Controller jederzeit im Bilde, wer gerade Owner 

so der Ressource ist. So kann beispielsweise in einem Fahrzeug dem Fahrer angezeigt werden, daB er seinen im Fond 
sitzenden Chef stort, wenn er den CD-Player bedient, da dieser gerade CD uber Kopfhorer hort. Er kann jedoch die 
Ressource mitbenutzen (Ressource Sharing), solange er sie nicht steuert (z.B. den Track wechselt). Schaltet der Chef 
auf Radio urn, merkt der Fahrer dies uber seine MMI und kann nun frei bedienen, da ihm die Ressource nunmehr gehort. 
[001 8] Auch Ressource Sharing im Zeitmultiplex ist moglich. So kann ein hochpriores Navigationssystem bei Bedarf 

55 auf die Karten-CD-ROM zugreifen und ein niederpriorer Reisefuhrer zwischenzeitlich auf eine andere CD-ROM im 
selben CD-Wechsler. Immer bei Bedarf verdrangt das Navigationssystem den Reisefuhrer mit ihrer hoheren Prioritat. 
In der Liste hat jeder Controller auch seine Prioritat mit eingetragen. Sie stellt neben der Zeit des Eintrags das Kriterium 
fur die Ressource zur Kennzeichnung des Owners, d.h. z.B. zum Sortieren der Liste dar. Der Controller, der nach dem 
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Sortieren am Anfang der Liste stent, ist der Owner der Ressource und kann auf den CD-Wechsler zugreifen. Die 
Reisefuhrer-Applikation kann ihrem Nutzer klarmachen, daB er ein wenig warten muB (z.B. durch Anzeige einer Sand- 
uhr). 

DererfindungsgemaBe Mechanismus erfordert keine aufwendige Kommunikation. Die Controller mussen keine kom- 
5 plizierten Annahmen uber Systemzustande machen, um zu entscheiden ob sie eine Ressource steuern konnen. Die 
Ownership ist nicht komplex im System verteilt und wird an mehreren Stellen (von mehreren Controllern) abgeleitet 
mit der Gefahr von Fehlinterpretationen. Sie ist nur an einer Stelle verankert - bei der Ressource selbst. Durch den 
einfachen Sortiermechanismus in der Liste der Ressource (siehe oben) ist jeweils klar, wer Owner ist. Jeder andere 
eingetragene Controller darf die Ressource sharen. Die Controller mussen sich auch nicht untereinander abstimmen. 
10 Der Speicher in jeder Ressource ist f luchtig und nur wahrend einer Betriebsphase wirksam. Bei einer neuen Betriebs- 
phase erfolgt automatisch ein Reset. 

[0019] Es erfolgt keine Priorisierung und Konfliktlosung auf unterer Hierarchieebene, d.h. in den Ressources selbst. 
Dies wurde umfangreiches und anderungsanfalliges Systemwissen erfordern. So muBte ein CD-Wechsler alle seine 
Anwendungen im System, sowie den momentanen Systemzustand kennen, um entscheiden zu konnen, wem Prioritat 
15 einzuraumen ist. Es wird lediglich ein Medium realisiert, das eine Entdeckung eines Konfliktes ermoglicht. Dieses 
Medium ist die erfindungsgemaBe Eigenschaft. 

[0020] Damit ergibt sich ein sicheres und aufgrund seiner einfachen Struktur fehlerf reies dezentrales Verfahren zum 
Ressourcen-Management verteilter Applikationen. 

20 

Patentanspruche 

1. Ressourcen-Management- Verfahren fur ein verteiltes System von Teilnehmern (i.f. "Ressourcen" genannt), die 
durch mehrere Controller gesteuert werden und die miteinander kommunizieren, dadurch gekennzeichnet, daft 

25 die Controller verschiedene und teilweise untereinander gleiche Prioritat besitzen, daB jede Ressource von einem 

Controller solange gesteuert wird, solange dieser und solange kein Controller mit hoherer Prioritat auf sie zugreift, 
daft von den Controllern , die die Ressource benotigen, der mit der hochsten Prioritat die Ressource steuert, und 
daB von mehreren Controller mit der gleichen hochsten Prioritat derjenige die Ressource steuert, der als erster 
auf sie zugreift. 

30 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daB jede Ressource selbst die Controller auflistet, die 
aktuell auf sie zugreifen. 

3. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, daB jeder Controller, der aktuell auf die Ressource zugreift 
35 sich in eine Liste der Ressource eintragt. 

4. Verfahren nach einem der Anspruche 1 bis 3, dadurch gekennzeichnet, daB jede Ressource die Liste der auf 
sie zugreifenden Controller auf Anforderung ausgibt. 

40 5. Verfahren nach einem der Anspruche 1 bis 4, dadurch gekennzeichnet, daB die Ressource auch den Controller 
kennzeichnet , der sie steuert. 
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